home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 4004 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.6 KB
  1. Path: news.bellglobal.com!stupy
  2. From: stupy@freenet.durham.org (Steve Tupy)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: What will happen close to 640K limit ?
  5. Date: 29 Jan 1996 14:57:47 GMT
  6. Organization: Durham Free-Net
  7. Message-ID: <4ein9b$330@news.bellglobal.com>
  8. References: <Pine.SOL.3.91.960128110843.26154C-100000@hamlet.uncg.edu>
  9. NNTP-Posting-Host: 204.101.165.17
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. : I wrote a DOS program, with size about 512K, which is the size when I use
  13. : dir to check it.
  14. :  
  15.     This may not be totally reliable...
  16.  
  17. : I also use dos command mem to check dos avaible memory, which gave me max
  18. : execute file size 560k, because there are some device driver I load in 
  19. : the config.sys, I knew 512k is not real program size, there are some 
  20. : stack variable and memory allocated on heap.
  21.  
  22. : Now my program is not stable, it can work for fine for couple days, then 
  23. : it lock up. It may just lock up keyboard or screen, it may also reboot 
  24. : PC, I wonder if because it close to 640 K limit ? How can I check the  real
  25. : program size include stack size and heap ?
  26.     
  27.     Because DOS is not reentrant, if you intend to run it for any length
  28. of time WITH memory allocation/deallocation, you almost MUST implement some
  29. sort of garbage collection scheme to "defrag" your memory segments. This is
  30. why you see all these BBS packages dumping out of memory and loading up
  31. again from the command line, it flushes the memory back to the original
  32. point, in a manner of speaking. You can either avoid memory allocation,
  33. implement a garbage collector or reload your program from time to time,
  34. these are about the only ways to deal with this problem that I know of...
  35.  
  36. Take care!
  37.  
  38. --
  39. Steve
  40.